Subject: IBM's Position on AP proposal for Automatic Data Conversion

From: "Chuck Terrien (254-4402)" <[email-masked]>
Date: Fri, 18 Mar 94 11:22:52 EST

Jack,

I am responding to you as the position taker for IBM in the CIW.  IBM
does not feel that the submission for Automatic Data Conversion
currently being assessed for AP is ready.  IBM's specific objections
are outlined below.

Generally, we have two sets of concerns.  We have concerns with the
requirements of this line item and we have technical concerns
with the proposal.  There was a great deal of discussion regarding the
requirements for Automatic Data Conversion in the CIW in December, but
this submission does not resolve the issues raised there.  We also have
technical concerns with the submissions that are specifically detailed
below.  Both sets of concerns are detailed below.

Our rationale for this disagreement is:

    - The requirements are not clearly understood and stated.
    - The design is incomplete.
    - It is not clear that the solution will work.
    - Some of the descriptions are inconsistent.

In order to resolve our objections and get AP we believe that
the proposal has to clearly state the requirements and that they are
agreed to in the CIW.  Secondly, the proposal has to address the
concerns outlined below.  Chung-huy Chen is the correct contact for
any of the concerns below.

If you or anyone in the ADC SIG has any comments or questions please
contact either Chen or me.

Regards,
Chuck Terrien

======================================================================

                 Detail of Concerns
                 __________________

Requirement-related concerns:
=============================
   1) What does a map name do for the program?
      The proposal includes two different views:
      - "... insulates a program from concerns about how the partner
         program views the data record."
      - "... allows the application programmer to be insulated from
         the network."

   2) Is it a requirement to perform data manipulation in addition
      to faithful data conversion?
      The proposal states that "the receiver may only require a
      subset of the data that was sent" and "the sending program
      may only send a subset of the required data."
      If so, how does it work?

   3) Is initialization/expedited data covered by data conversion?
      If so, how does it work?

Technical concerns:
==================

   1) Definition of a map name
      --> Lack of user's view and scope.

   2) Definition of a mapped conversation
      --> Lack of an explanation for the differences between a mapped
          conversation with a map name and that without a map name.

   3) Data conversion model
      --> Explain for both LU 6.2 and OSI TP CRMs:
          a) how three map names are correlated?  (They are two names
             used by the programs in conversation and one used by the
             network.)
          b) what is link-edited or becomes a DLL?  By whom?  When?

   4) Single map_name characteristic variable
      --> Incomplete design.  A race condition can occur between
          updating (e.g., as a result of receiving data) and
          referencing (e.g., in a process of sending data) the
          characteristic variable on a conversation.

   5) Length of a map name
      --> The proposal says both 1-64 and 0-64 bytes.

   6) Character set for the map_name characteristic variable
      --> Need a definition for both LU 6.2 and OSI TP CRMs.

   7) Relations of the proposed new calls to the conversation queues
      --> Undefined.

   8) Default mapping mechanism
      --> How does this work?

   9) Return codes and their descriptions on the proposed new calls
      --> Lack of appropriate reasons for state check (do we need this
          return code?), parameter check, and operation-not-accepted.

  10) Updating received map name
      --> When the update is performed is undefined.

  11) Usage note to the Receive call
      --> Clarify what should happen in the situation when both
          a map name and a deallocation notification are available
          to be returned to the program.